Sophisticated industrial processes, such as oil refining, automobile assembly or power generation, require the cooperative execution of numerous interdependent tasks by many different pieces of equipment. The enormous complexity of ensuring proper task sequencing and management, which requires not only procedural logic but constant monitoring of equipment states to organize and distribute operations and detect malfunction, has resulted in the widespread adoption of programmable controllers. These controllers operate elaborate industrial equipment in accordance with a stored control program. When executed, the program causes the controller to examine the state of the controlled machinery by evaluating signals from one or more sensing devices (e.g., temperature or pressure sensors), and to operate the machinery (e.g., by energizing or de-energizing operative components) based on a procedural framework, the sensor signals and, if necessary, more complex processing. The "inputs" to a particular controller can extend beyond the sensed state of the equipment the controller directly operates to include, for example, its environment, the state of related machinery or the state of its controllers.
Control requirements become even more complex when different aspects of the same overall process are assigned to remotely situated equipment. Such configurations often require reliable, high-bandwidth serial communication links to provide the necessary interconnection and handle data transfer among controllers and the sensors relevant to their operation.
Key to the proper operation and maintenance of programmable controllers (as well as the equipment they manipulate) is periodic auditing of equipment and controller states. Ordinarily, process operation is monitored, at least intermittently, by supervisory personnel by means of one or more central management stations. Each station samples the status of controllers (and their associated sensors) selected by the operator and presents the data in some meaningful format.
U.S. Ser. No. 08/851,644, the disclosure of which is hereby incorporated by reference, described use of the Internet and, more particularly, the interactive capabilities made available by resources such as the World Wide Web (hereafter the "web") to enable the controllers that actually gather data to determine how it is presented to a remote viewer. By packaging the control data as part of a web page (so that it appears as a static display or as the displayed result of a dynamic, self-updating program executing on the monitoring computer), the data is displayed in an optimal manner without regard to the capabilities or limitations of the monitoring computer. This avoids the need to equip monitoring computers with specialized graphic capabilities, as well as the need for intensive, ongoing cooperation between engineers responsible for programming controllers and those who configure the computers that perform monitoring. Moreover, because Internet users are typically billed for connectivity at a single rate, the long-distance charges that would accrue through use of telephone lines for data communication are eliminated.
In accordance with the '644 application, an integrated control system comprises one or more controllers each equipped to perform a control function and to gather data (ordinarily from sensors) relevant to the control function. "Relevant" data includes, at a minimum, any information upon which control decisions are made or states shifted, but can also include information obtained from sensors not directly connected to the controller (e.g., involving other controlled machines) but which is nonetheless meaningful to supervisory personnel. For example, a chemical synthesis process may be carried out at a temperature controlled to stay within an operating range, but the optimal temperature may depend on the output of a previous process feeding into the synthesis; in this case, the temperature of the synthesis process as well as the output of the previous process are relevant control parameters with respect to the synthesis process.
Each controller contains appropriate hardware and software for gathering, storing, and formatting the relevant data in accordance with instructions executable by the remote computer. The remote computer, in turn, receives the data and instructions, and in executing the instructions, presents the data in the desired format. Most typically, the remote computer runs a "web browser," and the controller maintains a "web page" that it serves to the browser upon connection. The web page comprises markup instructions that the browser executes, and which determine the appearance of the web page on the browser. Controller data are sent either as part of the markup instructions, resulting in a static display (i.e., one that can change only upon reloading of the web page by the browser); or in the form of program instructions that execute within the browser and thereby produce a dynamic display. The program instructions may direct not only the manner in which data is displayed, but also its gathering and periodic update. Thus, an "applet" might cause temperature data to be displayed as a graphical representation of a thermometer, with the height of the rendered mercury column dynamically varying in proportion to data periodically obtained from the controller by the remotely located browser.
The approach described in the '644 application facilitates a complete window into the operation of one or more controllers and, therefore, the industrial equipment they operate. Remotely located personnel can monitor he efficiency or overall behavior of the equipment, perform diagnostic checks, or even effect certain maintenance operations. For widely dispersed control and supervisory operations, supervisory computers interact with the controllers over the Internet, with the controllers continuously connected to the Internet as "nodes." In local operations, the flexibility conferred by Internet formalisms can be retained on a restricted, internal network.
The program code that operates industrial controllers, including the manner in which they gather and update data, has traditionally been procedural in nature. As described in U.S. Ser. No. 08/964,998, the disclosure of which is hereby incorporated by reference, procedural languages suffer from certain disadvantages; for example, functions and routines that are repeated must be programmed repeatedly, raising the prospect of error and, as the program becomes complex, obscuring its overall operation by the welter of detail. Furthermore, the frequently intricate, interdependent nature of industrial equipment can render a simple step-by-step procedural framework inadequate for controlling processes with reliability. The controller must be provided with (and its programming must accommodate) routines for handling "exceptions" ranging from sluggish component operation to complete failure of vulnerable components. These routines may take the form of diagnostic or "exception-handling" procedures. As branches from the primary control sequence, such routines further complicate programming in procedural systems.
Accordingly, the '998 application discloses a more sophisticated yet conceptually simpler paradigm for representing machine operation at the control level, and for programming control systems capable of directing the operation of complex industrial equipment and/or processes. This involves use of an object-oriented framework to "encapsulate" functions, attributes, and procedures, incorporating these within objects representing the entities most naturally associated with the encapsulated items. In this way, those items are established only once and utilized as necessary. An object may correspond to a part of a machine, to the machine itself, or to a class of machines; hierarchically superior (and conceptually more general objects) may be defined so as to be composed of "instances" of subordinate objects. For example, a "machine" object would contain procedures defining machine operations that the associated controller effectuates, as well as information facilitating orderly and reliable execution of those procedures.
In an object-oriented system, closely related data and procedures are treated as a single entity rather than separately. This is achieved by means of an object manager, which includes a database system to manage and organize the data corresponding to these entities or "objects." Design and implementation of object managers is well-known in the art. Basically, an object is a data structure and a set of operations and functions that can access that data structure. The data structure may, for example, be represented as a "frame" having a plurality of "slots," each of which contains an "attribute" of the frame. Each computational operation (a function, procedure, etc.) that can access the data structure is typically called a "method" or an "action."
The database contains a series of pointers associating each object with the methods and attributes (hereafter "object items") making up the object; those items may be stored anywhere--in volatile memory, on a mass-storage device, or even on a separate machine connected via a network interface. By organizing the object items, the database effectively permits each object to carry its own structure and orchestrate its own behavior. This permits the object frame to be "encapsulated" within the object methods; that is, access to the frame is handled primarily or exclusively by the surrounding methods, thereby ensuring data independence. Furthermore, because only the associated methods access the internal data structure, data integrity is maintained.